Currently, in the telephone industry, front end systems are provided that contain information about telephone customers, and particularly, telephone numbers, telephone service histories, and other relevant comments regarding, e.g., the customer's dwelling and service record. As shown in FIG. 1, such front end systems 50a,b, . . . 50n are commonly known as Loop Management Operating Systems (hereinafter "LMOS") and interface with a remote host mainframe computer 75 containing the primary service and operational databases. The front end systems 50a,b, . . . 50n maintain a facility for receiving telephone calls from customers requesting particular telephone service, e.g., when a telephone line or cable breaks, or when service is interrupted, etc., and service personnel enter details regarding the customer's complaint and service requested. Once the phone company investigates the particular problem(s) and determines the causality of the problem, it will dispatch maintenance personnel to rectify the problem.
As further shown in FIG. 1, each LMOS front end system deploys a plurality of screening maintenance centers ("SMC"), indicated as 80a1,2,3, . . . , 80b1,2, . . . and 80n1,2,3, . . . that respond to particular calls, e.g., associated with a particular area or maintenance center, etc., and typically may have up to several hundred SMCs. Furthermore, as shown in FIG. 1, embedded in the LMOS front end systems are rule-based expert systems 90a,b, . . . 90n that can automatically determine the nature of a trouble before dispatching a service rig, or, e.g., determine if the source of the problem is to be correctly assigned to that front end center. One expert system in particular is the screener decision unit ("SDU") which takes a trouble description, e.g., as typically called-in by a customer, looks at the various properties of the trouble, e.g., telephone number, exchange, etc., and looks to see if there is any way to automatically handle the call. For example, the SDU may automatically determine if another front end should be handling the call, or, automatically send the call to a dispatch maintenance center. All trouble calls are placed in a queue to await disposition via the expert systems just described. The queue contains, for each trouble, a pointer to relevant information such as customer name, telephone number, trouble code, etc. There is one queue for each SMC on the front end.
As shown in FIG. 2, the front end will generate a queue 85, corresponding to a particular SMC associated with that front end, with each queue containing pointers 86, as described above, that point to the particular record of the customer calling in the trouble situation. Depending upon circumstances, e.g., system load, etc., the queue for any given SMC at any given instant may have few or many pointers attached to it. These queues may increase or decrease in size, and, in extreme circumstances, may increase in size dramatically in very short period of times, for instance, when there is a storm or other natural disaster that interrupts telephone service. For example, as shown in FIG. 2, associated with front end 50n, one SMC queue, e.g., 80n.sub.m-1, may have ten customer complaints, i.e., pointers 86' associated with it, while another SMC queue, e.g., 80n.sub.m, being associated with an area having just incurred a natural disaster, may have tens of thousands of customer complaints, i.e., pointers 86" associated with that SMC. There is, in principle, no limit to the size of any queue, i.e., to the number of pointers (troubles) that may be enqueued upon it.
Currently, as shown in FIG. 2, each LMOS SDU employs a "Drainer" mechanism, indicated by arrow 99, that iteratively loops through all of the queues (one for each SMC) and selects the queue for screening in a fixed, orderly fashion, with the processing time allocated to a single SMC determined on the basis of three variable parameters: Queue Size (Q), the single-pass drain limit controlling how many pointers will be drained from the queue at a maximum before the Drainer passes on to examine the queue for the next SMC; Throttle Time (T), the predetermined amount of time that the process idles or sleeps after each item in the queue for that SMC is screened; and, Sleep Time (S), the time delay before the SDU begins to drain the next SMC queue. Thus, as an example, if there are greater or equal to"Q" troubles on a queue "x", and the throttle time is "t" seconds, then exactly Q troubles will be drained from the queue "x" in Qt seconds (ignoring processing overhead) when queue "x" is allocated its "turn" by the Drainer. The sleep time "s" is additional time the Drainer "rests" after processing a queue (and before it begins processing the next queue). By varying the Q,T and S parameters, it is possible to increase or reduce the time slice used by the Drainer relative to LMOS as a whole.
Currently, there is no mechanism for dynamically adjusting these parameters in response to changes in load distribution, i.e., unbalanced queue sizes. Thus, it is possible that some of the queues may increase in size to the point where a number of hours may elapse between the time a trouble is called in and the time that it is screened. Traditional queue management/queue selection techniques are not particularly useful in this connection because it is not possible to determine how many elements (pointers) reside on each queue.
Thus, it would be highly desirable to provide a mechanism that dynamically adjusts the S,T and/or Q parameters to properly balance the drain queue load and optimize Drainer performance in the face of unpredictable real-time demands.
Furthermore, it would be highly desirable to find a queue management system that manages queues in the absence of knowledge of the number of queues and size of each queue, since as mentioned herein, such knowledge is not readily available to the Drainer.